“Web services” is an industry term that covers a collection of standards and proposals that define how distributed computing should be implemented in a web-based network environment, such as the World Wide Web. Web services is an evolving area of technology that has a broad range of potential applications but is immature in implementation. There are several general attributes that describe the essence of web services.
The primary paradigm for web services is that of a client/server relationship. A client sends a request to a server for the execution of some task. The server executes the task and sends an appropriate reply back to the client.
Interoperability is a main goal of current web services efforts. Applying lessons from past mistakes, the industry is focusing its efforts on ensuring that information communicated between components of the system will be interpreted identically by all of the parties involved. The focus on “on the wire” representation has allowed for the development of very different (and competing) technologies for constructing web service implementations. Two of the major contenders at present include Microsoft, with its .NET architecture that leverages its traditional COM technology, and IBM, with its WebSphere architecture that leverages such Java technologies as Java 2 Enterprise Edition (J2EE).
Communication between client and server on the World Wide Web is typically accomplished via Hypertext Transport Protocol (HTTP). This is one of the factors that distinguish web services from other client/server approaches, such as remote procedure call (RPC) or common object request broker architecture (CORBA). Web service interactions also differ from those of typical Web browser interactions. In the typical browser interaction, the client sends a request for content from the server which will be rendered for display to an end user. In the web services model, the client sends a request for a task (or operation) to be executed by the server, and the reply contains the results of executing that operation.
Underlying most aspects of web services is the extensible markup language (XML). Most situations that call for representation of data employ XML as the base data structuring language. Most web services protocols are defined as a set of XML elements and conventions. This is another major factor that distinguishes web services from other client/server approaches. For example, CORBA employs one language (IDL) for defining interfaces and a different protocol (IIOP) for communicating between client and server. In the web services context, both the interface definition language and the client/server communication protocol are represented in XML.
There are two problems with XML, however, that probably originate from its original focus on supporting text processing. First, XML can be quite difficult and expensive to parse, due to such features as user-defined entities, processing instructions, etc., most of which are not needed for most inter-application communication. Second, as a text-based protocol, XML does not support the transport of raw binary information. Instead, it must be encoded into text for transmission (e.g., Base64 or similar encoding mechanisms).
There are essentially two approaches typically used for solving the first problem. The first approach is to define protocols that are based on the important core features of XML, but specifically forbid the use of particularly complex XML features (such as processing instructions). A recent example of this approach is the Simple Object Access Protocol (SOAP). See “Simple Object Access Protocol (SOAP) 1.1,” W3C Note, May 8, 2000. SOAP is an XML-based protocol that provides basic rules for the format of request and reply messages exchanged between client and server during operation execution. The second approach is to define a separate “logical” document model and then provide information to “map” that logical model onto the specific XML representation. A recent example of this approach is the Web Services Description Language (WSDL). See “Web Services Description Language (WSDL) 1.1,” W3C Note, Mar. 15, 2001. WSDL is an XML-based interface definition language that is used to define the operations supported by a server and how requests and replies for those operations are represented in the messages exchanged between client and server.
SOAP defines four basic things:    1) A subset of XML grammar that is allowed in a SOAP message (basically, it disallows certain complex XML constructs that are difficult to parse and are not applicable to a remote method invocation paradigm);    2) A basic document structure for SOAP messages that include:            a top level SOAP “Envelope” element within which all SOAP-related XML data must reside,        a SOAP “Header” element which is intended to contain all information pertaining to routing and handling of the SOAP document, and        a SOAP “Body” element which is intended to contain all information pertaining to execution of the specific request (or reply);            3) How “faults” (document processing or task execution errors) should be represented within the document; and    4) A suggested approach for representing typed data in SOAP documents (e.g., mappings from low-level host programming language variable types to XML).
WSDL defines a grammar for describing web service interfaces. A WSDL interface description consists of the following five top-level elements:    1) A single types element. Within this element, you define the logical types that you will be referencing later in the specification. Types may be simple (refer to single elements) or complex (combinations of elements, e.g. struct or array). Different typing systems may be used here, but the most common one employed is XML Schema;    2) A set of message elements. A message element corresponds to a single logical “message” that will be sent from client to server or vice versa. Messages consist of “parts”—each part has a type (defined within the types element);    3) A set of portType elements. A portType element corresponds to single logical service definition. Port types consist of a set of operation definitions. An operation has a name and the set of messages involved in requesting execution of that operation (typically a request message, a reply message, and a fault message);    4) A set of binding elements. Up to this point, everything covered in the WSDL document represents a “logical” view of the service. The purpose of the binding elements is to define how the logical messages are represented in a particular markup language/transport. Support theoretically exists for several XML-based transports, but the most common binding is to SOAP/HTTP. In that case, the binding involves mapping each part of each message to the appropriate section of the SOAP document and identifying the approach that will be used for encoding the logically-defined data types in SOAP (typically the SOAP encoding rules are used here); and    5) A service element. Where the binding element is used to map the logical representation to a markup/transport, the service element is used to identify the physical locations that support a particular portType/binding pair. For the typical SOAP-HTTP binding, this would normally consist of uniform resource locators (URLs) (including host and port).
A full WSDL specification thus consists of logical information (types, messages and portTypes), physical information (bindings), and location information (services). Since this information is typically needed by clients at different points in the development, WSDL specifications are often produced in fragments that are assembled together via an analog of the C pre-processor “#include” directive.
Aside from SOAP and WSDL, there are other initiatives that are often considered web services “building blocks”, such as XML schema and universal description, discovery, and integration (UDDI) protocol. XML schema provides a set of rules for defining logical data types in XML and is the preferred language for defining types in WSDL. UDDI is an XML-based protocol for obtaining information about the services provided by a particular organization. Typically, UDDI is used to retrieve the complete WSDL specifications (including location information) for a set of operations.
Combined, SOAP and WSDL perform three basic tasks when mapping information exchange onto a structured document:    1) Define a logical model for the interchange (the “parse tree” view of the problem). WSDL provides this.    2) Define a physical model for the interchange (the “on the wire” representation). SOAP provides this.    3) Provide a mapping between the logical and physical models. WSDL provides this.
Consider the following sequence of events, which describes a typical experience for a web services client developer:                The developer first obtains the “logical” portion of WSDL specifications for operations of interest via an “out of band” method, such as email or downloading from a web site.        The Developer imports the WSDL specifications into a web services toolkit and generates a native language (e.g., Java) client application programming interface (API) and writes code to that API.        At runtime, a complete WSDL specification for the operations of interest is obtained via UDDI from a service “registry” at the deployed site. The additional binding and location information in the “complete” WSDL files is necessary for actual communication between client and server (though it does not change the client API originally generated).        When runtime calls are made via the generated client API, they are translated into SOAP documents that are sent to the server via an HTTP POST. The server executes the requested operation and returns the results as a SOAP document via the HTTP POST reply. The returned document is parsed and used to populate the appropriate “output” parameters in the client API.        
The two basic approaches represented by SOAP and WSDL have shortcomings. For example, SOAP does not define how one represents the tasks to be executed by the server, how the data associated with the request and reply is structured, relationships between request and reply messages, or real-world issues such as application versioning. These issues must be coordinated between client and server “out of band”. WSDL addresses the “logical to physical” mapping problem by individually specifying how different elements in the logical model map to their counterparts in the physical model. Consequently, a consumer of such an interface must parse and understand such mapping instructions, which is not a trivial task. In addition, SOAP and WSDL are both XML-based. Consequently, without either changing the XML specification or manipulating the underlying transport (e.g., HTTP) protocol, one cannot pass binary data without encoding it as text. Other problems are associated with SOAP and WSDL, as described below.
Further, additional facilities are needed for effective implementation of typical web services, which are not provided by known current specifications. These facilities include user identification and authentication, access control, version management, transaction management, and ad hoc (dynamic) “batching” (sending several logical operation requests together in a single physical message).